Remove sybase use for star stats #337
Conversation
|
Regarding I did compare this current approach (fetching all acq and guide stats and then using non-indexed searches within them) to using the agasc_id indexes on the hdf5 tables (via tables.read_where). For an average set of stars in a schedule, it looks like using the indexed approach would reduce this part of the runtime by a bit more than a third (2.2 seconds to use the pre-fetch, 1.4 seconds to open the hdf5, keep it open, and do indexed queries). The 0.8 seconds did not seem worth it in this case (though fetching all the stats to start is not particularly memory efficient either). |
|
@taldcroft Do you want this to go too or would you like more time to consider? |
There was a problem hiding this comment.
Looks great! For testing I ran this on my Mac with JUN1019A and got reasonable results. As an extreme case abell 2146 obsid 20560 did show some diffs in the popup acq stats, but that might just be observations that happened between starcheck (flight) being run compared to the observation time which is what gets used for clipping results in the new version.
Is it an option (as a separate issue) to move most of the Python code into standalone modules in starcheck (the Python package)? That way you could put in unit testing and have your editor do PEP8 style checking etc.
One minor comment, I was just wondering if you actually need to make acqs and guides into astropy Table. I couldn't see anything that required this.
|
IIRC |
|
I can add a comment about that if it isn't going to be the convention to just |
|
Thanks for refreshing my memory. Indeed any data coming straight from HDF5 should generally be |
Remove sybase use for star stats
This is a redo of #257 and #187